Closed
Bug 304558
Opened 19 years ago
Closed 6 years ago
Bookmark All Tabs: A bad name is better than no name
Categories
(Firefox :: Bookmarks & History, enhancement)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: slaughter, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050812 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050812 Firefox/1.0+ A recent change means that when bookmarking a set of tabs, the folder name is "[Folder Name]" rather than the caption of the active tab. This creates a problem when multiple sets of tabs are saved temporarily. A common use-case for the Bookmark All Tabs feature is to quickly preserve a set of pages that will be revisited when time allows, after which the bookmarks will be discarded. The folder name is not important in such cases, providing it can disambiguate between other saved 'sessions', but that property has been lost. Reproducible: Always Steps to Reproduce: 1. Save a set of tabs, perhaps from Peter(6)'s Firefox build notes 2. Repeat with a set of tabs from a different window that you happen to have open 3. Pretend that you've upgraded Firefox and wish to resume browsing Actual Results: To determine which set of tabs is which, I must either name them differently in steps 1 and 2, or look at the names in the folder. Both methods slow me down and make the browsing experience more cumbersome. Expected Results: By choosing a 'reasonable' name as before, the sessions can be differentiated more easily. There's no magic answer for the folder name, but the best is the enemy of the good. The keyboard access to bookmark all tabs is also more difficult. There's no (obvious) accelerator on the menu, nor shortcut key to open the dialogue. While the changes make the Bookmark All Tabs feature more prominent, I feel it was already readily discoverable when adding bookmarks and the visibility doesn't justify these impediments. I have raised this as a bug rather than an enhancement, because I feel it is a significant usability regression. Please amend if necessary.
Comment 1•19 years ago
|
||
No data is lost and it's just a name. So this is very much an enhencement/request for improvement.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•19 years ago
|
OS: Windows XP → All
Hardware: PC → All
Version: unspecified → Trunk
Comment 2•19 years ago
|
||
I suspect this was changed here with the patch for bug 300412: var dialogArgs = currentTabInfo; + if (aBookmarkAllTabs) { + dialogArgs = { name: gNavigatorBundle.getString("bookmarkAllTabsDefault") }; + dialogArgs.bBookmarkAllTabs = true; + } See also the comments in that bug. So it was done on (semi-)purpose, and that would mean this bug could become a WONTFIX.
Blocks: 300412
Reporter | ||
Comment 3•19 years ago
|
||
(In reply to comment #2) > See also the comments in that bug. I didn't see any that were relevant. Was there some discussion as to why the change to the default folder name was made? It seems "obvious" that there's no single correct name for the folder, and therefore natural that this is a consequence, until you consider the usability issues it introduces. For me, not having a shortcut key to bookmark all tabs and being forced to choose a name is something of a nuisence. > So it was done on (semi-)purpose, and that would mean this bug could become a > WONTFIX. As long as someone understands the issue and considers it before doing that, I'll be content.
Comment 4•19 years ago
|
||
Well, it wasn't specifically commented in bug 300421, but I was more or less coming to the conclusion in comment 2, because of the lack of protest from the reviewers in the patch for bug 300421. cc-ing the patch-maker of bug 300412, gsshih@gmail.com (I hope you don't mind).
Comment 5•19 years ago
|
||
Er, comment 4: where I said bug 300421, I meant bug 300412.
The reason why the default name was changed was from usability studies showing that users were confused about the name being one of the bookmarks. Perhaps if the label value of the textbox showed "Folder Name: " instead of "Name: " while keeping the original default would be better? -grace
Comment 7•19 years ago
|
||
Changing the textbox label would definitely help: .---------------------------------------------------, | Add Bookmarks for All Tabs | |---------------------------------------------------' | Folder Name: [ Tabs from 2005-08-01 ] | | Create In : [ Bookmarks |v] [v] | | | | [ OK ] [ Cancel] | '---------------------------------------------------' If we can come up with some relatively reasonable heuristic to use as a default name for the folder, I'd rather see that than something that *must* be replaced. Also, when the auto-filled content is constant (instead of based on selection) we run the risk of presenting a default value that could easily create duplicate entries :( Maybe something based on the current date and time (shown in example above)? Or "%firstTabName - %secondTabName"? Grasping at straws a little here ...
Comment 8•19 years ago
|
||
Looking at this from a step back, I'm becoming more convinced that the problem is a mismatch between the action name ("Bookmark all Tabs") and the end result (a folder of bookmarks is created). Nowhere do we tell the user that the thing they create is a folder of bookmarks. In my above ASCII art, I changed the title of the dialog from "Bookmark All Tabs" to "Add Bookmarks for All Tabs". Not that I seriously believe that anyone reads those things, but perhaps "Add Folder for Bookmarks from Tabs" would be better?
Comment 9•18 years ago
|
||
Can't reproduce with places-enabled build. Worksforme?
Comment 10•18 years ago
|
||
Certainly not WFM: the reporter's original concern was that telling two folders quickly saved, both named "[Folder Name]" made it difficult to tell them apart. Now his two quickly saved folders will both be named "". If the Places version is using a blank default for very carefully tested reasons that overrule the reporter, and the original implementer, and MoCo's UI lead, then WONTFIX would be the appropriate resolution.
Comment 12•6 years ago
|
||
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•